1. The Field of the Invention
The present invention relates to manipulating data used to generate graphical objects. More specifically, the present invention relates to using externally parameterizeable constraints in a font-hinting language to synthesize font variants.
2. Background and Related Art
Computing technology has transformed the way we work and play. Computing systems now take a wide variety of forms including desktop computers, laptop computers, tablet PCs, Personal Digital Assistants (PDAs), and the like. Even household devices (such as refrigerators, ovens, sewing machines, security systems, and the like) have varying levels of processing capability and thus may be considered computing systems. As time moves forward, processing capability may be incorporated into a number of devices that traditionally did not have processing capability. Accordingly, the diversity of computing systems may likely increase.
Almost all computing systems that interface with human beings use a display to convey information. In many cases, the appeal of the display is considered an important attribute of the computing system. Display of textual information (e.g., Latin-based characters) typically includes processing glyphs that represent characters of a font. A glyph includes control points and instructions for connecting the control points such that an outline of a corresponding character can be generated in an arbitrary grid space (e.g., a pixel grid). Often, characters will be defined for display at a larger size and higher resolution and then mathematically scaled down (or otherwise manipulated) when the characters are to be rendered at smaller sizes and lower resolutions (or as bold, italic, etc.). Thus, a reduced number of descriptions, and potentially only one description, for a character (per font) need be stored.
To scale a character down the location of control points can be divided by a scaling factor. For example, to scale a character down by a scaling factor of 10, the coordinates of each control point defining the character (at the higher resolution) can be divided by 10. It may be that control points defining a character for display on a 100×100 grid are to be scaled down for display on a 10×10 grid. Thus, a control point at grid position (50, 30) can be scaled down to a control point at grid position (5, 3), a control point at grid position (70, 70) can be scaled down to a control point at grid position (7, 7), etc. Accordingly, a smaller outline representing the character may be calculated and there is a reduced need for storing a number of different sizes of bit-maps for the character.
The smaller outline can then be analyzed to identify grid locations that are to be turned on and to identify grid locations that are to be turned off (a process often referred to as “scan conversion”). One scan conversion algorithm determines if the center of a grid position is inside or outside the smaller outline. When the center of a grid position is inside the smaller outline the grid position is turned on. On the other hand, when the center of a grid position is outside the smaller outline the grid position is turned off.
However, at times, and especially at lower resolutions, the results of scan conversion produce an unacceptable representation of a character. Unacceptable character representations can result from rounding errors in the scaling down process. Further, rounding errors have a greater affect on character representation when a single grid location (e.g., a pixel) is on scale with the features of a character. For example, a rounding error that causes one grid location to be inappropriately turned on (or turned off) on a 50×50 grid may not even be detectable by the human eye. However, a rounding error that causes one grid location to be inappropriately turned on (or turned off) on a 4×4 grid may result in a character that is perceived as unacceptable to the human eye. At lower resolutions scan conversion can even fail to preserve the topology of the original outline of the character, resulting in disconnected grid locations.
To compensate for the sometimes inappropriate results of scan conversion, character outlines can be supplemented with constraints (often referred to as “hints”) that assist in identifying whether grid locations are to be turned on or turned off when a character is rendered. The highest quality hinting is typically a manual process performed by a typographer. The typographer views a character at various sizes and supplements a higher resolution outline of the character with computer-executable instructions that indicate how to render the character at lower resolutions. When the character is to be rendered, a computing system processes the computer-executable instructions and renders the character in accordance with the hints implemented in the computer-executable instructions. For example, a hint can indicate that a number of characters of a font are to be rendered at the same height.
More formally, a hint can be expressed as an algorithm defining one or more dependent parameters in terms of one or more independent parameters. Hints for one control point can be expressed in terms of the location of other control points or locations on a grid (e.g., a capitalization line). For example, the position of a control point “P” can be expressed in terms of the position of a control point “Q” such that P is a fixed distance “c” from Q (e.g., in a vertical or horizontal direction). That is, P=Q+c. Thus, when Q is moved, a corresponding move of P may be required so that P conforms to the fixed distance c.
Similarly, the position of the control point P may be expressed in terms of the position of two other control points “Q1” and “Q2,” along with a number “α” to indicate the degree of blending of the positions of the two control points “Q1” and “Q2.” The position of the control point “P” is assigned the expression “(1−α)·Q1+α·Q2.” That is, P=(1α)·Q1 +α·Q2. Thus, when Q1 or Q2 is moved, a corresponding move of P may be required so that P conforms to the constraint.
Due in part to the wide variety of different artistic and technical features in different fonts, hints can be tailored to an individual font. Often, constraints are expressed in terms of a font-hinting language (e.g., the TrueType® language) having a limited and highly specific vocabulary. The limited and highly specific vocabulary simplifies the translation of the mathematical concepts into the font-hinting language. However, the limited and highly specific vocabulary can also limit the types of the constraints that can be expressed.
Fonts are typically stored in font files at a computing system where the characters of the fonts will be rendered. Applications, such as, for example, word processors and electronic mail clients, provide an interface for selecting fonts from among those fonts available at a computing system. Many applications also provide an interface for selecting the size of a selected font (e.g., 12 point, 8 point, etc.) and selecting font variants for the selected font (e.g., bold, italicized, subscript, superscript, small caps, etc.). Based on the selected font size, selected font variant, and resolution of the output device, a scaling module and hint processor can interoperate to generate an appropriate outline for rendering characters of a font. For example, a scaling module and hint processor can interoperate to generate appropriate outlines of bold 10 point characters at 96 dots per inch (“dpi”).
Due to the wide range of font variants, constraints for some font variants are not necessarily appropriate for other font variants. Accordingly, there may be a number of font files for a font, each font file corresponding to one or more font variants. For example, there may be separate font files for Arial normal and bold characters, Arial superscript characters, and Arial small caps characters.
Unfortunately, most applications that allow font variant selection do not necessarily check to determine that all appropriate font files are accessible. That is, an application may provide an interface for selecting a subscript font variant even when the application lacks access to a corresponding subscript font file. Further, users expect a number of font variants to be available irrespective of the availability of corresponding supplemental font files and are often not even aware that each font variant may require a supplemental font file. As a result, applications can have a default algorithm that selects a similar font file when a font variant is to be rendered. For example, when lacking access to an Arial subscript font file, an application may simply select an Arial normal font file. However, since the normal font file is not hinted for rendering subscript characters, pixelation or other visual deficiencies may result.
Some mechanisms attempt to compensate for visual deficiencies that can result from using a mismatched font file to render a font variant. However, these mechanisms typically result in characters that no longer comply with hints included in the font file. Since hints are an important part of high quality font rendering, it may be difficult to appropriately render font variants, especially at small type sizes and on low resolution. Therefore, what would be advantageous are mechanisms for generating a font variant that complies with hints of the font used to generate the font variant.